Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@lib/distributedLock.js`:
- Around line 52-69: The current acquireLock in distributedLock.js only sets
lockedUntil once (in acquireLock) which allows the lease to expire during long
runs; add a renewal/heartbeat mechanism and a safe renew API: implement a
renewLock({name, holder, ttlMs}) that performs a conditional findOneAndUpdate
matching {_id: name, holder} and sets lockedUntil to now+ttlMs (return true only
if holder matches), call that renew periodically from the long-running worker
while it holds the lock (e.g., setInterval cleared on finish) and ensure
renewLock validates ttlMs like acquireLock; alternatively implement a fencing
pattern by embedding a monotonic epoch/token (holder already used) and always
require the holder match when extending or releasing so a stale process cannot
steal the lock.
- Around line 19-35: The new shared distributed lock (LockSchema and exported
CronLock) must live under the approved shared code locations; either move this
module into lib/helpers/ or lib/services/ and update all imports that reference
CronLock to the new path, or if there is a deliberate exception, add a
top-of-file comment justifying why it must remain at lib/distributedLock.js
(include owner, rationale, and link to the exemption approval) and run a
repo-wide search to update/verify imports; ensure the exported symbol CronLock
and the schema name LockSchema remain unchanged so dependent modules still
resolve correctly.

In `@modules/billing/crons/billing.dunningSweep.js`:
- Around line 119-122: The logger.error call in the dunningSweep lock-release
failure currently passes metadata first and message second; change it to pass
the message string first and the metadata object second (i.e., flip the
arguments for logger.error) so it matches the rest of the file and other billing
crons—update the call that references LOCK_NAME and releaseErr in the
dunningSweep lock-release error handling to use logger.error(message, { err:
releaseErr, cron: LOCK_NAME }).

In `@modules/billing/crons/billing.extrasExpiration.js`:
- Around line 89-92: The logger.error call that currently passes meta first
should be changed to message-first ordering to match other calls: call
logger.error with the string '[cron.extrasExpiration] failed to release lock —
will auto-expire on TTL' as the first argument and the metadata object { err:
releaseErr, cron: LOCK_NAME } as the second; update the logger.error invocation
that references releaseErr and LOCK_NAME in the extrasExpiration cron to use
this ordering so breadcrumb format is consistent.

In `@modules/billing/crons/README.md`:
- Around line 136-139: Update the runbook section reference in the README:
replace the text `## Cron lock stuck` with the exact header `## 6 — Cron lock
stuck` so the link/mention matches the actual section title in the billing
runbook; edit the sentence in modules/billing/crons/README.md that currently
reads "See the runbook entry `## Cron lock stuck` in
`modules/billing/RUNBOOKS.md` for manual resolution." to use the exact header
`## 6 — Cron lock stuck`.